[POC] Add a new Strict parser #164
Conversation
|
I like the concept. You are correct this would be a huge, potentially breaking change. I would see the rollout as something like
I could also see a world where 2.0.0 requires the parser be explicitly set so that no one is caught off guard. Then in 2.1.0 (or even 3.0.0) we set the default to the new strict parser. |
|
Are there any plans on moving forward with this strict parser? |
|
I have not heard a strong outcry for—or against—moving forward. Given that, the default is to keep the status quo. |
|
At the risk of being a Johnny-come-lately, I like this idea, but I also feel the "strict" parsing has its own burden of opinions. I feel like a more flexible approach might be better. Here are two ideas: First idea: Support custom parsers and document strict parsing
Second idea: Support granular configuration
Tests would need to be present and pass in either case. What do you all think? |
|
I think both are good ideas. However, they are both a lot of work that someone needs to feel passionate enough to undertake. |
|
been a year. closing. |
Opening this PR to start a discussion on the current approach to parsing.
Over time I have worked/consulted for a few companies that use this gem internally. However all of them had to monkey-patch the gem in order to significantly restrict string parsing (especially when it comes to user input and even developer input).
The main issues being:
29.01.2023,29,12,12, etc)one1two2three3)10,000and10,00yield different results)I think that the current approach is "find any signs of monetary amount in the input". While this works for some use-cases, I would argue that this might not be the best default behaviour. For any company providing financial services or even consumer retail this unfortunately is straight unacceptable.
Therefore I'm proposing adding an optional strict parser (and potentially making it default). This parser takes a different approach — it finds known good partial matches (currency, symbol, amount, etc) and then checks it against allowed formats (e.g.
[:symbol, :amount]for$99.99). This allows gem users to ensure that only allowed formats are matched and no unwanted characters were present.The PR is a proof of concept and passes most specs with expected exceptions related specifically to:
€10,000as 10K, instead of 10 (should be tweak-able)£.45Bas this is a rarely accepted formatnilwhen parsingnil(happy to change this toMoney.empty)19.12.89as this doesn't look like an amountThis is a big(ish) change, so I'd like to gather more input from others before I make further progress.
Any questions, concerns and feedback is very welcome! 🙌